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ABSTRACT 

The  application  of  Computer  Aided  Design  (CAD) 
and  Manufacturing  (CAM)  techniques  in  the  marine 
industry  has  increased  significantly  in  recent 
years,  With  more  individual  designers  and  ship 
yards  using  CAD  within  their  organizations,  the 
pressure  to  transfer  CAD  data  between 
organizations  has  also  increased.  The 
Navy/Industry  Digital  Data  Exchange  Standards 
Committee  (NIDDESC)  prow-ales  a  mechanism  for 
public  and  private  organizations  to  cooperate  in 
the  development  of  digital  data  transfer 
techniques . 

Organizationally  NIDDESC  is  a  cost-sharing 
venture,  between  private  firms  and  government 
organizations .  This  effort  arose  from  the  Naval  Sea 
Systems  Command  (NAVSEA  )  in  cooperation  with  the 
National  Shipbuilding  Research  Program.  The 
members  include  leading  professionals  in  the 
marine  industry  from  several  major  design  firms, 
private  ship  yards,  naval  ship  yards,  and 
government  laboratories .  All  members  are  directly 
involved  in  CAD/CAM  in  their  organizsations  and 
together  represent  a  broad  spectrum  of  experience 
and  perspectives . 

NIDDESC  has  many  sub-committees  devoted  to 
specific  areas  of  digital  data  transfer.  The  basic 
objective  is  to  develop  an  industry-wide  consensus 
on  product  data  models  for  ship  structure  and 
distribution  systems.  Efforts  include  contributions 
to  the  Initial  Graphics  Exchange  Standard,  the 
Product  Data  Exchange  Standard,  preparation  of  a 
Recommended  Practices  Manual  and  the  analysis  of 
ship  production  data  flows .  NIDDESC  has  made 
contributions  to  the  development  of  CALS 
standards  including  MIL-STD-1840,  DOD-IGES, 
SGML,  and  MIL-D-28000. 

INTRODUCTION 

Nature  of  The  Ship  Design  Process 

The  information  exchange  problem  of  the  Navy 
and  the  marine  industry  is  one  of  the  most 


challenging  faced  by  any  group  of  organizations 
in  the  world.  This  is  due  to: 

*  The  complexity  of  the  product, 

*  The  life  span  of  the  product,  and 

*  The  number  of  participants  in  the  design, 
construction  and  service  life  support  process. 

Naval  ships  are  among  the  most  complex  devices 
known  to  man.  Their  design  and  construction 
requires  from  7  to  12  years .  They  roam  the  oceans 
for  30  years  following  their  construction.  They 
accomplish  complex  missions  in  hostile  environments 
while  providing  hotel  accommodations  for  their 
operators.  Only  a  few  of  each  type  are  built,  with 
each  hull  differing  to  some  extent  from  her  sisters. 
By  the  standards  of  most  industries,  these 
collections  of  8,000,000  or  so  parts  are  all 
engineering  prototypes . 

Unlike  aircraft  and  most  mechanical  products, 
ships  are  not  designed,  built,  operated,  maintained, 
and  modernized  by  vertically  integrated  corporate 
giants .  Rather  these  functions  are  accomplished  by 
a  series  of  government  activities  and  private 
companies .  Competitive  pressures  make  it 
impossible  to  know  in  advance  who  the  participants 
in  the  process  will  be.  Further,  the  process  itself 
tends  to  vary  somewhat  from  ship  to  ship. 

All  of  the  activities  and  companies  involved  have 
improved  this  process  by  utilizing  computer  tools. 
For  example,  many  major  builders  have  found 
Computer  Aided  Design  (CAD)  applications  a  cost- 
effective  means  of  avoiding  costly  interferences 
during  construction. 

The  automation  efforts  within  each  activity  or 
company  have  required  subatantial  investments  in 
hardware  and  software  (  both  custom  and 
commercial) ,  in  training,  orientation,  and  adaptation 
of  work  processes  to  capitalize  on  computer 
capabilities .  The  range  and  extent  of  investment  is 
even  more  impressive  considering  the  general 
decline  and  low  profitability  of  the  marine 
industry.  There  can  be  no  denying  that  the  marine 
industry  is  serious  about  CAD! 

Investment  choices  made  by  different  activities 
and  companies  have  quite  naturally  led  to  the 
selection  of  different  systems .  Even  companies 
with  identical  systems  have  developed  different 
application  techniques .  Together  with  the 
variations  in  the  process  noted  above,  the  Navy 
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and  the  marine  Industry  are  squarely  faced  with  a 
requirement  to  be  able  to  transfer  product 
information  between  and  among  all  activities  and 
companies.  This  transfer  must  take  place  at  all 
stages  of  the  product  life  cycle  including  design, 
construction,  and  service  life  support . 

Purpose  of  NIDDESC 


Enable  the  Exchange  of  Digital  Data.  This  is  the 
ultimate  challenge .  Following  a  history  of  niddesc 
and  identification  of  the  participants,  is  a 
description  of  how  NIDDESC  has  broken  this 
problem  into  manageable  pieces  and  is  developmg 
solutions  for  the  critical  ones. 

History  of  the  Program 


One  primary  effort  by  the  Navy  and  the  marine 
industry  to  address  this  requirement  is  the 
Navy/Industry  Digital  Data  Exchange  Standards 
Committee  (NIDDESC) . 

NIDDESC  is  a  cost  sharing,  cooperative  effort 
involving  Navy  &  Industry  technical  experts  in  CAD 
applications . 

NIDDESC  seeks  to  avoid  costs  associated  with 
regeneration  of  data  bases  by  enabling  the 
exchange  of  digital  data  between  successive  agents 
during  the  ship  life  cycle. 

Cost  Sharing  Cooperative  Effort .  The  NIDDESC 
effort  is  being  executed  through  a  National 
Shipbuilding  Research  Program  (NSRP)  style 
cooperative  agreement  between  the  Maritime 
Administration  and  Newport  News  Shipbuilding. 
Newport  News  has  executed  purchase  orders  with 
each  of  the  commercial  participants .  Under  the 
terms  of  the  cooperative  agreement,  each 
commercial  participant  has  waived  profit  and  all 
but  direct  labor  fringe  overhead.  Thus,  the 
companies  involved  are  absorbing  one-third  to  one- 
half  of  the  labor  costs. 

Technical  Experts .  The  Working  Group  is 
comprised  of  the  CAD  Manager  or  a  principal 
deputy  from  each  of  the  companies  and  activities . 
Each  member  typically  has  5-15  years  experience 
developing  and  introducing  CAD  to  complex  ship 
design,  construction,  and  support  activities.  As  a 
result  NIDDESC  is  a  standard-setting  activity 
working  at  the  leading  edge  of  CAD  application 
technology. 

Avoid  Cost .  The  costs  associated  with  the 
regeneration  of  ship  technical  data  by  successive 
agents  during  the  ship  life  cycle  are  substantial. 
These  costs  are  usually  budgeted  as  expected  costs 
of  doing  business  using  traditional  techniques .  A 
few  examples  hint  at  the  cost  avoidance  potential: 

*  Bath  Iron  Works  was  able  to  avoid  96%  of  the 
labor  (approximately  a  manyear)  usually 
associated  with  production  lines  fairing  on  the 
DDG51  by  capitalizing  on  digital  hull  form 
information  made  available  by  NAVSEA.  This 
was  possible  as  a  result  of  a  technology 
transfer  developed  under  the  Research  and 
Engineering  for  Automation  and  Producibility  of 
Ships  (REAPS)  Project  in  the  1970' s. 

*  PDS  350  and  PMS  400  have  spent  several 
million  dollars  each  on  digital  data  exchange 
programs  for  the  SEAWOLF  and  DDG51  classes 
respectively.  In  each  case,  they  were  able  to 
justify  the  costs  of  the  digital  data  exchange 
program  based  on  an  expected  reduction  in  the 
rate  of  follow  builder  claims  for  geometric 
discrepancies . 


NAVSEA  has  responsibility  for  the  design, 
acquisition,  and  service  life  support  of  Naval  ships. 
During  the  course  of  the  ship  life  cycle,  NAVSEA 
contracts  with  numerous  design  agents, 
shipbuilders,  equipment  vendors,  and  logistics 
agents  to  fulfill  this  responsibility.  These 
organizations  have  individually  developed  or 
acquired  various  computer  systems  to  support 
their  efforts .  The  result  of  their  individual 
selections  and  the  highly  competitive  nature  of  the 
Naval  ship  design,  construction,  and  service  life 
support  process  present  a  generic  need  on  the 
part  of  the  Navy  and  the  marine  industry,  to 
transfer  digital  data  among  different  computer 
systems . 


This  need  was  foreseen  by  many  Navy  and 
industry  leaders,  and  was  formally  articulated  in 
Toward  More  Productive  Naval  Shipbuilding,  a 
National  Academy  of  Sciences/National  Research 
Council  report  sponsored  by  NSRP  and  issued  in 
December  1984 .  As  a  result  of  several  meetings 
following  the  issue  of  this  report,  NIDDESC  was 
formed  in  June  1986  as  a  joint  project  of  NAVSEA 
and  NSRP.  The  Honorable  Everett  Pyatt,  Assistant 
Secretary  of  the  Navy  for  Shipbuilding  and 
Logistics  was  instrumental  in  the  formation  of 
NIDDESC.  His  office,  together  with  various  ship 
acquisition  projects  and  the  Computer  Aided 
Acquisition  and  Logistics  Support  (CALS)  program, 
has  provided  most  of  the  financial  support .  The 
participants  in  NIDDESC  are  shown  in  Table  I . 


Table  I .  NIDDESC  Participants 


Navy 
CHENG-L 
CEL-PA 
DTRC 
PDS  350 

Puget  Sound  NSY 
NAVSEA  05 
NAVSEA  06 
NAVSEA  93 
SEACOSD 
SupShip-Bath 


Industry 

Bath  Iron  Works 

Designers  &  Planners 

Electric  Boat 

Gibbs  &  Cox 

Ingalls  Shipbuilding 

JJH 

NAS SCO 

Newport  News  Shipbuilding 
The  Jonathan  Corporation 
The  Baham  Corporation 


The  NIDDESC  working  group  executed  a  Plan  of 
Action  and  Milestones  (POA&M)  approved  by  the 
NIDDESC  steering  group  in  August  1986  and 
updated  in  September  1987.  By  May  1989,  the 
working  group  had  substantially  completed  this 
POA&M  at  approximately  65%  of  the  projected  cost . 
While  there  were  literally  hundreds  of  interim 
products,  the  salient  accomplishments  under  this 
POA&M  were : 

*  Establishing  an  approach  to  the  transfer  of 
the  ship  definition  data, 

*  Establishing  marine-industry-wide  agreement 
on  the  structural  and  piping  information  to  be 
transferred,  and 
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*  Influencing  national  and  international 
standards  development  efforts  to  support 
marine  industry  needs . 

In  May,  1989,  the  steering  group  approved  a 
second  POA&M  to  guide  the  next  phase  of  NIDDESC 
efforts .  The  working  group  efforts  continue  under 
this  POASM. 

OVERVIEW  OF  NIDDESC  APPROACH 

In  breaking  down  the  digital  date  transfer 
problem  into  achievable  pieces,  NIDDESC  has  been 
guided  by  a  few  fundamental  principles  concerning 
digital  data  transfer.  The  first  principle  is  that  all 
digital  data  transfer  projects  require  the 
completion  of  four  steps  before  an  assured  data 
transfer  capability  exists.  The  second  principle  is 
that  all  transferred  ship  information  falls  into  four 
categories . 

Development  of  an  Assured  Data  Transfer  Process 
Capability 

The  development  of  an  assured  data  transfer 
capability  involving  any  type  of  information, 
exchange  technique,  or  media  can  be  divided  into 
four  steps.  Specifically,  they  are: 

Step  1.  Identify  Data  for  Transfer.  NIDDESC  is 
applying  information  modeling  technology  to  obtain 
explicit  agreement  on  the  information  to  be 
transferred.  Information  modeling  allows  a  precise 
statement  of  complex  entities  and  relationships 
between  data  types  with  minimal  ambiguity.  The 
resulting  model  is  in  a  form  understandable  by 
computer  specialists,  engineers,  and  managers. 
This  model  is  the  basis  for  the  data  transfer 
process.  This  step  is  not  expensive,  but  takes 
time. 

Step  2.  Define  Data  Format.  Once  the  subject 
data  is  determined,  a  data  transfer  format  can  then 
be  defined.  The  DoD  CALS  initiative  has 
emphasized  the  development  of  computer-based 
design,  construction,  and  maintenance  processes 
through  national  standards  and  DoD  applications  of 
these  standards .  NIDDESC  is  committed  to  this 
approach.  A  data  transfer  capability  built  on  these 
standards  can  achieve  significant  economies  baaed 
on  commercially  developed  and  supported  software. 
Like  step  1,  this  step  is  not  expensive,  but  also 
takes  time.  NIDDESC  has  a  number  of  tasks, 
described  later,  aimed  at  assuring  that  national  and 
DoD  standards  support  the  marine  industry. 

Step  3 .  Develop  or  Acquire  Translators .  This 
step  requires  a  substantial  investment  of  resources 
and  time.  It  is  principally  a  software  development 
effort  that  can  only  be  undertaken  when  the 
requirements  (i.e.  data  to  be  transferred)  and  the 
design  (i.e.  format  of  transfer)  are  completed. 
NIDDESC  is  not  involved  in  the  development  or 
acquisition  of  digital  data  translators.  In  this  area, 
NIDDESC  is  looking  to  the  development  of 
commercial  translators  based  on  CALS  standards . 
This  approach  has  been  confirmed  with  the 
development  of  the  Initial  Graphics  Exchange 
Standard  (IGES) .  With  each  successive  release  of 
IGES,  commercial  products  have  become  available 
implementing  portions  of  the  new  standard. 


where  specific  ship  projects  have  economically 
pressing  needs  for  data  exchange  capabilities 
which  are  beyond  the  scope  of  commercial 
products,  NIDDESC  can  facilitate  the  development  of 
specific  software  by  having  completed  steps  1  and 
2. 

Step  4.  Test  and  Validate  Transfer  Techniques. 
Testing  and  validation  brings  the  data  transfer 
capability  to  a  production  status .  This  step  may 
require  substantial  resources  and  time.  Extensive 
testing  and  validation  is  required  prior  to 
contractual  data  transfers.  Due  to  resource 
constraints  and  the  project-specific  nature  of  test 
and  validations  efforts,  NIDDESC  is  minimally 
involved  in  this  area. 

Ship  Product  Model  Information  Categories 

Ship  technical  information  falls  into  four  broad 
categories  as  illustrated  in  Figure  1 .  These 
categories  have  different  characteristics  and  uses. 

The  first  category  is  Requirements  information. 
The  ship  is  designed,  acquired,  and  maintained  to 
fulfill  some  set  of  functional  and  mission 
requirements  These  guide  the  initial  ship 
Definition  which  is  analyzed  for  its  ability  to  fulfill 
these  requirements.  During  the  design  stages,  the 
ship  Definition  becomes  more  explicit  and 

procedural  specifications  are  developed  to  guide 
further  design  efforts.  Ship  requirements  data 
must  be  accessible  not  only  in  design  and 
construction  stages,  but  also  in  service  life  stage 
to  determine  suitability  of  alternate  components  or 
configurations  during  maintenance  and 

modernization  efforts . 

The  process  of  developing  the  Associated 
Technical  Products  may  highlight  areas  where  the 
ship  Definition  needs  modification.  Alternately 
Requirements  frequently  change  during  the  7  to  15 
year  duration  of  the  design  and  construction 
stages .  All  of  the  Associated  Technical  Products 
have  the  characteristic  that  a  change  in  ship 
Definition  invalidates  them  to  some  extent  and 
requires  them  to  be  updated  or  regenerated. 

During  the  design  stages  many  analysis  models 
and  analysis  results  are  created  based  on  the 
developing  ship  Definition.  Analysis  results  are 
evaluated  against  functional  and  mission 
requirements  and  provide  the  basis  for  ship 
Definition  changes  and  Requirements  for  successive 
stages . 

As  the  production  planning  and  fabrication 
stages  begin,  fabrication  and  assembly  instructions 
are  developed  and  purchase  orders  are  generated. 
Test  plans  and  instructions  are  developed  to  verify 
that  Requirements  have  been  satisfied.  Operating, 
maintenance  and  training  plans  and  support 
requirements  generally  are  developed  by  the 
shipbuilder  as  part  of  an  integrated  logistics 
support  package. 

Configuration  Accounting  information  is  needed 
to  support  various  configuration  management  and 
change  control  processes  applied  to  the  ship 
Definition,  the  Associated  Technical  Products,  and 
to  the  Requirements.  This  information  is  comprised 
of  approval  status :  hull  applicability  and  product 
structure  information.  This  latter  is  most 
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frequently  system-oriented  ESWBS  numbers,  but 
at  various  stages  can  be  compartment-oriented 
and/or  assembly-oriented  numbering  systems . 

Definition  information  is  the  representation  of 
the  ship  that  we  want  to  design,  build,  operate,  or 
maintain.  Definition  includes  geometry  (shape), 
topology  (what  pieces  are  connected  to  what) ,  and 
material  (what  it's  made  of)  data.  Because 
combatant  ships  these  days  resemble  floating 
computers  which  behave  differently  with  different 
programming,  embedded  software  is  included. 

All  these  categories  of  information  are  of  prime 
importance  to  complete  one  task  or  another. 
Analysis  reveals,  however,  that  almost  every  task 
requires  Definition  information.  This  lead  NIDDESC 
to  focus  on  Definition  data  as  the  key  element.  The 
additional  realization  that  the  ship  is  constantly 
changing  has  also  forced  NIDDESC  to  include  a 
minimal  amount  of  Configuration  Accounting 
information  in  their  initial  scope. 

All  of  these  categories  of  information  are 
developed  and  many  are  communicated  today  via 
traditional  media  including  drawings  and 
documents .  It  is  clear  that  the  marine  industry  is 
in  the  process  of  a  media-shift  from  paper-based  to 
computer-based  procedures .  What  is  not  so  clear 
is  that  there  are  many  degrees  of  computerization. 

The  simplest  degree  of  computerization  is 
"Image  Capture.''  At  this  level  the  computer  can 
display  a  video  image  of  the  paper  product  which 
can  be  reproduced  or  replaced  relatively 
conveniently.  Otherwise  it  has  few  advantages  and 
some  disadvantages  compared  to  traditional  media. 

The  next  degree  of  computerization  is  the  "2-D 
CAD  Drawing."  In  addition  to  the  advantages  of 
"Image  Capture"  this  degree  allows  ad  hoc  changes 
of  scale  and  content  and  portrayal  of  alternate 
configurations .  A  trained  user  is  still  required  to 
understand  the  3-D  product  being  displayed,  and 
even  trained  viewers  frequently  develop  different 
mental  images  based  on  the  same  set  of  drawings . 

The  next  degree  of  computerization  is  the  "3-D 
CAD  Model."  In  addition  to  the  advantages  of  the 
"2-D  CAD  Drawing"  this  degree  allows  ad  hoc 
changes  of  the  viewpoint  and  assures  that  all  views 
represent  the  same  3-D  product .  This  makes  it 
easier  for  any  user  to  form  a  correct  mental  image 
of  the  product  and  makes  interference  detection 
possible. 

The  next  degree  of  computerization  is  the 
"Builder's  Definition."  In  addition  to  the 

advantages  of  the  "3-D  CAD  Model"  this  degree 
allows  computer  checking  of  comp  onent 
compatibility  (no  flanged  joints  to  threaded 
connectors  )  and  association  of  CAD  models  to 
material  control  systems,  weight  control  systems, 
etc. 

NIDDESC  has  chosen  to  operate  at  the  builder's 
definition  degree  of  computerization.  This  is  the 
degree  that  leading  builders  are  utilizing  in  their 
detail  design  and  construction  systems  and  which 
is  of  the  most  potential  economic  benefit  for  lead- 
builder  follow-builder  data  transfers.  Additionally 
this  is  the  degree  of  computerization  which  the 
Navy  will  be  able  to  capture  as  the  basis  for 


service  life  support  and  modernization  design. 
Finally,  this  degree  of  computerization  can  be 
decomposed  to  a  lower  degree  easily,  whereas  the 
opposite  movement  is  difficult  if  not  impossible. 

Implementation  of  NIDDESC  Objectives 

NIDDKSC's  basic  objective  is  to  develop  an 
industry-wide  agreement  regarding  the  data  to  be 
transferred.  Once  the  data  set  for  transfer  has 
been  defined,  it  is  possible  to  define  the  format  for 
transfer,  develop  the  transfer  software  and  test 
the  results  in  a  manufacturing  environment .  The 
progressive  nature  of  Digital  Data  Transfer  (DDT) 
implementation  can  be  depicted  in  three  intervals 
of  time: 

1.  Near-Term  Implementation  (  1  Year), 

2.  Mid-Range  Implementation  (2-5  Years),  and 

3.  Long-Range  Implementation  (5+  Years) . 

NIDDESC  is  persuing  data  format  definition  tasks 
designed  to  bring  results  in  each  time  frame .  In 
this  way  the  NIDDESC  program  can  support  current 
ship  design  efforts  and  lay  the  groundwork  for 
future  procurements .  Each  of  these  time  frames 
requires  a  unique  approach  as  the  CAD  systems, 
data  transfer  standards  and  ship  construction 
projects  change.  An  overview  of  the  NIDDESC 
approach  is  shown  in  Table  II . 


Table  II.  Overview  of  NIDDESC  Approach 

I.  Basic  Objective  -  Identify  Data  for  Transfer 

A.  Analyze  Data  Flows 

B.  Electrical  Systems  Data  Model 

C.  Catalogs  for  Distribution  Systems 

D .  Combat  Systems 

E.  Outfitting  &  Furnishings 

II.  Near-Term  (1  Year)  Implementation 

A.  Recommended  Practices  Manual 

B.  MIL-D-28000  Application  Protocol  for  3-D  Pipe 

III.  Mid-Range  (2-5  Year)  Implementation 

A.  IGES  Implementation  Baaed  on  HVAC  Model 

B.  IGES  Implementation  Based  on  Structural 
Model 

IV.  Long-Range  (5+  Year)  Implementation 

A.  PDES  Inputs  for  Structure 

B.  PDES  Inputs  for  Distribution  Systems 

C.  PDES  Logistics  Models/Information 


The  Development  of  Basic  Agreement  Tasks  will 
identify  the  data  for  transfer.  These  include  the 
analysis  of  data  flows,  ship  product  models  and 
catalogs  for  these  models . 

The  Near-Term  Implementation  Tasks  are 
designed  to  give  nearly  immediate  enhancements  in 
the  ability  to  transfer  CAD  data.  These  tasks  make 
use  of  current  CAD  platforms  and  IGES  Application 
Protocols .  Also  included  is  the  development  of  a 
Recommended  Practices  Manual . 

The  Mid-Range  Implementation  time  frame  of  2 
to  5  years  dictates  enhancements  to  present 
platforms  and  CAD  software.  These  tasks  focus  on 
incremental  enhancements  to  IGES. 
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The  Long-Range  Implementation  Tasks  are 
designed  to  take  advantage  of  the  next  generation 
of  CAD  systems .  These  CAD  systems  will  utilize  The 
Product  Definition  Exchange  Standard  (PDES) . 
PDES  will  include  the  definition  of  data  at  the 
engineering  object  level. 

BASIC  OBJECTIVE  -  IDENTIFY  DATA  FOR  TRANSFER 

The  basic  objective  of  the  NIDDESC  project  is 
the  development  of  an  industry-wide  agreement 
regarding  the  information  to  be  transferred, 
information  modeling  techniques  are  used  by 
software  developers  to  define  data  and  a  framework 
for  understanding  that  data. 

Information  Modeling  Techniques 

At  this  point,  a  few  words  on  information 
modeling  techniques  will  help  to  provide  a  context 
for  the  discussion  that  follows .  An  information 
model  is  simply  a  blueprint  for  understanding 
information.  It  provides  a  means  for  unambiguous 
communication  between  individuals .  An  information 
model  defines  a  common  context  for  the 
interpretation  of  information.  The  modeling 
process  is  independent  of  computer  technology. 

NIDDESC  has  developed  information  models  of 
ship  systems  using  the  Nijssen  Information 
Analysis  Method  (NIAM)  ,  (1)  .  A  NIAM  diagram 
defines  entities  and  their  relationships .  Entities 
can  be  objects  or  concepts .  They  are  represented 
by  circles.  The  second  major  element  in  NIAM 
diagrams  are  roles .  Roles  define  the  relationships 
between  entities .  They  are  represented  by  boxes 
that  contain  verb  phrases .  In  NIAM  diagrams  the 
relationships  between  entities  can  be  read  as 
simple  English  sentences .  This  provides  another 
means  of  representing  the  model  which  can  be  used 
for  verification. 

There  are  several  types  of  constraints  in  NIAM 
diagrams  that  apply  to  entities  and  the  roles 
between  them.  Constraints  are  the  rules  of 
behavior  invoked  when  entering  of  retrieving  data. 
They  guarantee  the  consistency  of  the  information. 
Constraints,  in  combination  with  entities  and  roles, 
provide  a  complete  definition  of  the  database.  This 
definition  allows  individuals  to  communicate  via  the 
database .  It  can  be  used  within  one  computer  or 
as  the  basis  of  transferring  information  between 
different  computers . 

A  complete  information  model  includes  diagrams, 
English  statements  derived  from  the  diagrams  and 
a  dictionary  definition  for  every  entity. 

NEAR-TERM  (1  YEAR)  IMPLEMENTATION 

One  thrust  of  the  NIDDESC  implementation  effort 
is  the  development  of  digital  data  transfer 
standards  for  CAD  systems  equipped  with  IGES 
translators .  These  systems  provide  real  and 
immediate  capabilities  within  present  limitations.  In 
addition,  the  development  of  these  near-term 
implementations  provides  test  cases  for  emerging 
national  standards . 

Recommended  Practices  Manual 

This  document  presents  recommended  practices' 
for  digital  data  transfer  among  various  government 


agencies,  ship  yards  and  design  agents.  Included 
in  the  scope  is  transfer  between  NAVSEA 
headquarters,  Lead  Builder,  Follow  Builders  and 
Planning  Yards .  The  entire  ship  life  cycle  is 
covered  in  this  analysis;  including  design, 
construction,  maintenance  and  overnaul  of  Navy 
ships .  The  manual  is  based  on  experience  gained 
from  current  ship  acquisition  projects  Including 
DDG51  and  SEAWOLF . 

The  manual  is  divided  into  two  parts .  The  first 
part  includes  a  general  Introduction  of  the 
management  of  digital  design  information 
throughout  the  ship  life  cycle .  The  second  part 
provides  specific  solutions  on  the  types  of  data 
and  the  transfer  mechanisms  to  be  employed. 
Alternative  solutions  are  provided  that  are  time 
dependent  based  on  anticipated  Improvements  in 
hardware  and  software  capabilities  and  the 
implementation  of  national  and  international 
standards .  The  manual  is  coordinated  with  current 
published  or  developing  standards  such  as  MIL-D- 
28000.  The  manual  also  includes  draft  ship 
specifications,  Contract  Data  Requirements  List,  and 
contractual  inputs  for  inclusion  in  future 
contracts . 

IGES  Application  Protocols 

The  IGES  standard  (2)  was  developed  to  provide 
the  means  of  transferring  graphic  data  from  one 
CAD  system  to  another  using  a  universal  data  file 
format .  The  IGES  standard  is  comprised  of  entities 
that  represent  elements  commonly  found  in  CAD 
systems.  To  date,  none  of  the  major  CAD  systems 
vendors  have  provided  a  full  implementation  of  the 
IGES  standard.  However,  each  has  implemented  a 
portion  of  the  standard  using  the  entities  that  most 
closely  represent  the  capabilities  of  their 
respective  systems . 

In  order  to  use  these  IGIS  translators 
successfully,  it  is  necessary  to  limit  the  product 
modeling  to  the  subset  of  entities  available  on  the 
target  CAD  systems .  Once  this  subset  is  defined, 
it  is  necessary  to  prescribe  a  relationship  between 
the  CAD  system  entities  and  the  product  elements 
that  they  define.  Finally,  a  test  program  is 
necessary  wherein  the  elements  of  the  CAD  model 
are  carefully  tested  with  data  that  is 
representative  of  the  design  data.  It  is  only  after 
this  process  is  complete  that  the  successful 
transfer  of  CAD  data  with  IGES  entities  can  be 
achieved. 

The  procedure  described  is  often  known  as  an 
IGES  Application  Protocol  (AP) .  The  development  of 
AP's  can  require  significant  resources.  If 
organizations  were  to  develop  these  procedures 
independently,  there  would  be  a  major  duplication 
of  effort.  In  addition,  the  resulting  AP's  would  be 
unique.  The  goal  of  universal  data  transfer 
offered  by  the  IGES  standard  would  be  lost.  The 
National  Institute  of  Standards  and  Technology 
(NIST)  has  recognized  the  need  for  standard  AP's 
and  has  developed  a  guide  for  their  development 
(3) .  NIST  is  working  with  members  of  the  IGES 
Organization  to  develop  AP's.  As  they  are 
developed,  AP's  will  be  submitted  for  inclusion  in 
MIL-D-28000.  AP's  identify  the  information 
requirements  of  a  particular  engineering  discipline 
(such  as  3-Dimensional  Piping)  using  the 
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terminology  and  practices  particular  to  the 
discipline.  AP's  include  the  following  elements. 

1.  Information  Models.  The  first  step  in  the 
development  of  an  AP  is  the  definition  of  the  data 
comprising  the  product  model .  This  model  is 
independent  of  any  CAD  system  implementation  and 
can  be  validated  by  an  expert  from  the  application 
area.  Once  the  model  is  defined  the  IGES  entities 
are  selected. 

2.  Format  Specification.  Along  with  the 
information  models,  it  is  necessary  to  develop  a 
usage  guide  for  the  selected  IGES  entities  that 
defines  restrictions  on  the  global  and  parameter 
data  sections  of  the  IGES  rile. 

3.  Test  Cases.  The  final  portion  of  the  AP 
includes  the  protocol  test  cases .  The  test  cases 
include  test  data  and  a  test  methodology  including 
procedures  and  criteria  for  evaluating  the  test 
results. 

The  NIDDESC  project  is  contributing  to  the 
development  of  Application  Protocols  in  three 
technical  areas,  including: 

*  3-Dimensional  Piping  Model, 

*  HVAC  Model,  and 

*  Ship  Structural  Model. 

3-Dimensional  Piping  Model 

The  3-Dimensional  Piping  IGES  Application 
Protocol  (4)  being  developed  by  NIDDESC  is  based 
on  the  model  developed  under  the  SEAWOLF  Digital 
Data  Transfer  Program.  The  SEAWOLF  model  has 
been  has  been  generalized  and  expanded  for  this 
effort .  This  AP  is  geared  to  using  IGES  constructs 
and  entities  to  pass  enough  information  to  capture 
the  design  and  permit  the  fabrication  of  a  piping 
system.  No  attempt  has  been  made  to  pass  either 
preliminary  design  concepts  or  life  cycle  and 
logistical  information.  The  AP  makes  use  of  IGES 
Version  4 . 0  with  the  addition  of  version  5 . 0 
attribute  data.  The  AP  enables  the  exchange  of  the 
following  piping  entities: 

*  Pipes 

*  Stave  Damping  Assemblies 

*  Joints 

*  Hangers 

*  Catalog  Parts 

*  Components 

*  Attachments 

*  Product  Structures 

*  Piping  Attributes 

Figure  2  presents  the  NIAM  diagram  showing 
the  piping  parts  relationships .  The  Piping  Part 
entity  is  represented  as  a  solid  circle  in  the  center 
of  the  diagram.  Solid  circles  are  used  to  define 
real  world  objects.  In  this  case,  Pipe,  Piping  Part, 
Geometry,  etc.  are  all  components  of  ship  piping 
systems .  These  components  are  related  in  two 
major  ways .  The  first  type  of  relationship  is  the 
subtype  relationship.  This  is  shown  by  a  line 
pointing  from  the  subtype  to  the  supertype  such 
as  the  relationship  between  Pipe  and  Piping  Part . 
All  instances  of  subtype  are  automatically  instances 
of  the  supertype  and  all  properties  of  the 
supertype  are  inherited  by  the  subtype.  As  entity 
relationships  can  be  read  in  both  directions,  the 


relationship  between  Piping  Part  and  Pipe  can  be 
read  as  follows : 

A  Pipe  is  a  kind  of  Piping  Part. 

a  Piping  Part  may  be  a  Pipe. 

The  second  type  of  relationship  between  entities 
is  the  role  relationship.  This  can  be  illustrated  by 
the  Product  Structure  and  Piping  Part  relationship. 
A  Product  Structure  is  an  aggregation  of  parts  for 
a  specific  purpose  or  function.  A  product 
structure  may  be  a  System,  Assembly,  Drawing  or 
Pipe  Run.  In  NIAM  diagrams,  the  role  relationship 
is  depicted  by  a  rectangular  box  divided  in  half. 
This  box  contains  verb  phrases  that  describe  the 
binary  role  relationships .  In  this  case  the  roles 
can  be  described  as  follows : 

A  Product  Structure  may  associate  any  number 
of  Piping  Parts. 

A  Piping  Part  may  be  associated  by  any  number 
of  Product  Structures . 

The  role  relationship  is  subject  to  various 
constraints  that  serve  to  further  define  the 
relationship.  One  such  role  restraint  is  simple 
uniqueness.  This  means  that  the  role  is  unique. 
This  constraint  is  shown  by  a  double  arrow  by  the 
role.  Uniqueness  is  paraphrased  "only  one."  A 
second  constraint  is  simple  totality.  This  means 
that  the  relationship  between  the  object  and  the 
role  must  always  occur.  This  constraint  is  shown 
by  a  "V"  drawn  on  the  line  connecting  the  role  and 
object.  Totality  is  paraphrased  "every."  The 
relationship  between  Piping  Part  and  Pipe  Port 
demonstrates  both  the  uniqueness  and  totality 
constraints.  In  one  direction,  no  constraints  apply: 

A  Piping  Part  has  any  number  of  Pipe  Ports. 

However,  the  converse  relationship  contains  both 
uniqueness  and  totality  constraints  as  follows: 

Every  Pipe  Port  is  of  only  one  Piping  Part. 

With  the  rules  described  above,  the  relationships 
of  Piping  part  to  the  other  entities  of  can  be  read 
as  follows : 

A  Pipe  is  a  kind  of  Piping  Part. 

A  Component  is  a  kind  of  Piping  Part. 

A  Piping  Part  may  have  any  number  of  Pipe 
Ports. 

Every  Pipe  port  is  of  only  one  Piping  Part. 

Every  Piping  Part  has  only  one  Attribute  Set. 

Every  Attribute  Set  is  of  only  one  Piping  Part. 

Every  Piping  Part  has  only  one  Geometry. 

E-very  Geometry  is  of  only  one  Piping  Part. 

A  Piping  Part  may  be  attached  by  any  number  of 
Attachments . 

Every  Attachment  attaches  only  one  Piping  Part. 

A  Piping  Part  may  be  associated  by  any  number 
of  Product  Structures. 

A  Product  Structure  may  associate  any  number 
of  Piping  Parts 

A  NIAM  diagram  showing  Pipe  and  IGES 
Relationships  is  given  in  Figure  3.  Please  note  this 
figure  was  developed  to  define  the  Pipe/ IGES 
relationships .  Other  relationships  have  not  been 
included  for  the  purpose  of  clarity. 
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Figure  2 


NIAM  Diagram  of  Piping 

(JP'jC'om  7S7XL>£>ESC  IGES  EjLj=hs 
Ajpjplj.ceL't-i-on  .IPjroizoco.L  ) 


Figure?  3  —  N  I. AM  l)i  Jigrani  of  EC3KH 

1  nii>l  <  sinen  tut. i  on  Pi  |>e 

(  f - 'mm  A 1 1  in  )1‘.\ SY  "  1  <  71  i'G  I  >i 

/\/>p  7  i  c'£i  t.  ion  Pro  f.ooo  7  y> 


In  Figure  3,  the  top  half  of  the  circle  symbol 
defines  the  piping  elements,  the  lower  half  of  the 
symbol  defines  the  IGES  entity  used  to  represent 
the  piping  element .  IGES  has  no  specific  entity  for 
pipe,  therefore  it  is  necessary  to  select  from  the 
available  entities  one  which  will  represent  pipe.  In 
this  case  the  Composite  Curve  (Entity  102)  was 
chosen.  The  use  of  the  Composite  Curve  Entity  is 
not  unique,  it  is  also  used  to  represent  piping 
joints  (such  as  tees  and  elbows)  and  pipe  stave 
damping.  As  the  Composite  Curve  is  used  to 
represent  several  piping  elements,  it  is  necessary 
to  differentiate  between  the  applications.  This  is 
done  through  the  use  of  the  Attribute  Set  as 
follows : 

Every  Pipe  has  only  one  Pipe  Attribute  Set. 

Every  Pipe  Attribute  Set  has  only  one  Part 
Type,  only  one  Catalog  ID  Number,  only  one  Nominal 
Pipe  Type,  only  one  Nominal  Pipe  Size,  only  one 
Part  ID,  and  only  one  Attribute  Set  Definition. 

A  Pipe  Attribute  Set  may  have  any  number  of 
Optional  Attributes. 

The  Pipe  Attribute  Set  is  represented  by  the 
IGES  Attribute  Table  (Entity  422,  Form  0) .  The 
Attribute  Set  Definition  is  represented  by  Table  4 
of  the  IGES  Attribute  Table  Definition  (Entity  322, 
Form  0).  In  IGES  version  4.0,  this  list  contains 
only  17  attributes.  This  AP  makes  use  of  attributes 
18  through  27  which  have  been  approved  by  the 
IGES  committee  and  will  be  included  in  IGES 
version  5.0. 

The  Pipe  geometric  definitions,  also  shown  in 
Figure  3,  can  be  described  as  follows: 

Every  pipe  has  only  one  Path  Geometry. 

A  Path  Geometry  has  only  Lines  and/or  Arcs. 

Note  the  "T"  between  the  Line  and  Arc  objects. 
This  is  a  subtype  total  constraint  which  connects 
all  valid  subtypes.  From  the  above  discussion,  the 
centerline  of  a  pipe  is  totally  defined  by  any 
number  of  lines  (IGES  Entity  110)  and/or  circular 
arcs  (IGES  Entity  100) . 

Note  the  "X"  between  the  near  roles  for  the 
Pipe  End.  This  is  a  role  exclusion  constraint  which 
indicates  that  the  roles  are  mutually  exclusive. 
The  treatment  of  pipe  ends  can  be  read  as  follows: 

A  Pipe  may  have  one  or  more  Pipe  Branches. 

Every  Pipe  starts  at  only  one  Pipe  End. 

Every  Pipe  ends  at  only  one  Pipe  End. 

Every  Pipe  End  either  starts  a  Pipe  or  ends  a 
Pipe. 

The  complete  AP  (4)  contains  similar  diagrams 
for  Component  Occurrence,  Pipe  Hanger,  Stave 
Assembly,  Joint,  Attachment,  Product  Structure, 
Catalog  Part,  Catalog  Part  Geometry  and  External 
Reference . 

HID-RANGE  (2-5  YEAR)  IMPLEMENTATION 

The  mid-range  implementation  time  frame  of  2  to 
5  years  dictates  enhancements  to  presently 
available  platforms  and  CAD  software.  During  this 
time  frame  the  majority  of  CAD  system  users  will 
upgrade,  but  not  completely  replace,  their  present 
investment .  This  time  frame  allows  for  revisions  of 
the  IGCS  standard.  In  order  to  take  full  advantage 


of  IGES  standard  development,  NIDDESC  has  sent 
representatives  to  the  quarterly  IGES  meetings . 
The  goal  of  this  activity  is  the  development  of 
extensions  to  IGES  that  will  facilitate  the  transfer 
of  ship  product  data.  This  effort  has  taken  direct 
advantage  of  the  SEAWOLF  DDT  program  for  ship  3- 
Dimensional  pipe  and  the  data  transfer  specification 
developed  for  the  DDG51  DDT  project.  The  results 
of  this  effort  will  be  available  for  mid-range  ship 
acquisition  programs,  CALS  and  other  Navy  CAD 
data  transfer  requirements . 

NIDDESC  plans  to  continue  these  mid-range 
implementation  activities  with  the  following  efforts: 

*  Participation  in  the  IGES  Organization, 

*  IGES  Changes  for  HVAC,  and 

*  IGES  Changes  for  Ship  Structure. 

LONG-RANGE  (5+  YEARS  )  IMPLEMENTATION 

IGES  is  the  data  transfer  standard  presently  in 
use  in  the  CAD  industry.  It  was  developed  to 
transfer  graphical  data  entities  between  different 
CAD  systems.  In  practice,  designers  employ  these 
CAD  entities  to  represent  physical  entities.  The 
relationship  between  CAD  entity  and  the  physical 
entity  is  often  inferred  and  does  not  reside  within 
the  computer  database .  Future  CAD  systems  are 
being  designed  to  resolve  this  problem.  These  CAD 
systems  will  possess  databases  that  allow  the 
definition  of  physical  entities.  For  instance,  Figure 
3  shows  the  relationship  between  piping  elements 
and  the  IGES  entities  that  represent  these 
elements .  In  future  CAD  systems  this  relationship 
will  be  an  integral  part  of  the  system,  transparent 
to  the  designer. 

The  Product  Definition  Exchange  Standard 
(PDES)  is  being  developed  to  take  advantage  of  the 
ability  of  future  CAD  systems  to  define  product 
models .  PDES  will  provide  for  the  transfer  of  this 
product  data  without  loss  of  information  or  the 
introduction  of  ambiguities.  To  achieve  this  goal, 
PDES  development  requires  a  three  layer 
architecture  including  applications  layer,  logical 
layer  and  physical  layer.  Information  models 
required  to  communicate  between  these  layers  are 
being  developed  by  experts  in  several  engineering 
disciplines . 

PDES  version  1.0  (5)  was  published  in  the  fall  of 
1988.  It  included  mechanical  piece  parts, 
mechanical  assemblies,  electrical  printed  wiring 
board  products,  AEC  models  (including  the  ship 
structural  model)  ,  FEM  models  and  drafting 
applications .  NIDDESC  contributed  the  AEC  ship 
structural  model  and  has  since  begun  the 
development  of  a  distribution  systems  model . 
NIDDESC  plans  to  continue  the  PDES  development 
effort  with  the  following  tasks : 

*  Participation  in  PDES  Organization, 

*  Reference  Model  for  Ship  Structural  Systems, 

*  Reference  Model  for  Distribution  Systems,  and 

*  Reference  Model  for  Ship  Logistics  Data. 

PDES  Ship  Structural  Model 

The  NIDDESC  Reference  Model  for  Ship 
Structural  Systems  (6) ,  was  endorsed  by  the  PDES 
Architecture,  Engineering  and  Construction 
Committee  in  October  1988.  The  goal  of  this 
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document  was  the  developmentof  a  ship  structure 
information  model  that  allows  the  transfer  of  the 
majority  of  the  ship  structure  without  manual 
Intervention  or  interpretation  of  the  results.  This 
model  has  been  incorporated  into  the  first  draft  of 
the  PDES  standard,  and  as  such  is  being  reviewed 
and  revised  by  the  members  of  the  PDES 
Organization.  The  Ship  Structural  Systems  model 
defines  the  ship  structural  product  at  the 
completion  of  detailed  design  and  lofting.  Nesting 
data  has  heen  excluded  as  it  is  typically  unique  to 
individual  ship  yards .  The  ship  product  model 
includes  the  following  geometric,  topological  and 
property  information: 

*  Molded  Hull  Lines; 

*  Stiffened  Surfaces  (shell,  bulkheads,  decks, 
etc)  : 

*  Cutouts,  Lightening  Holes  and  Penetrations; 

*  Weld  Data  and  Bevels : 

*  Stiffener  Data; 

*  Material  Definition  (thickness,  type,  material) ; 

*  Brackets,  Collar  Plates; 

*  Stanchions; 

*  Units/Assemblies; 

*  Foundations;  and 

Rudder . 

Definitions .  The  definition  of  the  ship 
structural  product  model  is  contained  in  a  series  of 
NIAM  diagrams  showing  the  relationships  between 
ship  structural  elements.  The  relationship  between 
hull,  assembly  and  subassembly  is  represented  in 
the  NIAM  diagram  shown  in  Figure  4 .  The  elements 
shown  have  the  following  definitions : 

*  Hull:  Collection  of  Systems  which  comprise  a 
ship. 

*  System:  Functionally  related  group  of 

elements . 

*  Structural  System:  Collection  of  structural 
parts  used  to  divide  and  support  other 
Systems . 

*  Unit  Assembly:  Collection  of  parts  and/or  Sub- 
Assemblies  in  a  logical  or  physical  grouping. 

*  Sub  Assembly:  Collection  of  parts  and/or  other 
Sub-Assemblies  in  a  logical  or  physical 
grouping . 

*  Part :  Unique  structural  element  or  component 
consumed  during  the  production  process . 

*  Material:  Substance  making  up  a  part 

including  description  of  material  and 
properties . 

*  Path  Segment :  Bounded  portion  of  a  molded 
curve  beginning  and  ending  at  nodes . 

Relationships .  These  elements  have  the 
following  principal  relationships  as  shown  in  the 
figure : 

Every  hull  is  made  up  of  one  or  more  Systems. 

a  Structural  System  is  a  kind  of  System. 

Every  Structural  System  is  made  up  of  one  or 
more  Unit  Assemblies . 

A  Sub-Assembly  is  a  kind  of  Unit  Assembly. 

A  Sub-Assembly  may  be  made  up  of  Sub- 
Assemblies  and/or  Parts. 

Every  Part  must  be  of  exactly  one  Sub- 
Assembly. 

Every  Part  must  be  either  a  Plate  Part,  Shape 
Part  or  Library  Part. 


Every  Part  must  be  Identified  by  only  one  Part 
ID,  creased  at  only  one  Date/Time  and  made  of  only 
one  Material. 

A  Material  may  be  used  for  any  number  of  Parts. 

In  this  network,  it  can  be  seen  that  the 
structure  of  the  ship  hull  is  comprised  of  plate, 
shape  and  library  parts .  The  model  defines  the 
relationships  of  each  of  these  parts .  For  the 
purpose  of  brevity,  the  following  discussion  will 
be  limited  to  shape  parts .  The  complete  model 
defines  relationships  of  plate  and  library  parts  to 
a  similar  level  of  detail. 

Figure  5  presents  a  NIAM  diagram  showing 
structural  shape  relationships .  Structural  shapes 
attach  to  a  surface  or  plate  along  a  straight  or 
curved  line .  They  have  standard  or  non-standard 
cross  sections.  They  may  be  twisted.  They  are 
intercostal  or  continuous .  They  are  bounded  by 
surfaces,  plates  or  other  shapes.  Shapes  have  end 
cuts  which  can  take  on  a  wide  variety  of 
configurations .  The  following  relationships  can  be 
seen  from  the  figure: 

Every  Shape  Part  must  start  with  only  one  End 

Cut. 

Every  Shape  Part  must  end  with  only  one  End 
cut. 

A  Shape  Part  is  defined  by  any  number  of  Path 
Segments. 

A  Shape  Part  has  any  number  of  Shape  part 
Edges . 

Every  Shape  part  is  oriented  by  one  or  more 
Shape  Orientations. 

Every  Shape  Part  is  Iota  ted  by  only  one  Shape 
Reference  Point. 

Every  Shape  part  starts  with  only  one  Shape 
Clearance  and  ends  with  only  one  Shape  Clearance . 

Every  Shape  Part  is  offset  by  only  one  Shape 
Surface  Offset . 

Every  Shape  Part  is  identified  with  only  one 
Cross  Section . 

A  Shape  Part  is  marked  by  any  number  of  N/C 
Marks . 

A  Shape  Part  is  joined  by  any  number  of  Nodal 
Joints. 

Every  Shape  Part  is  identified  with  only  one 
Shape  Part  Type . 

The  complete  model  (6)  contains  descriptions  of 
ship  geometry  and  topology,  parts  (including  plate, 
shape  and  library) ,  joints  and  openings . 

PDES  Distribution  Systems  Model 

In  addition  to  the  Ship  Structural  Model, 
NIDDESC  is  developing  a  Distribution  Systems  Model 
for  the  PDES  standard.  Like  the  Ship  Structural 
Model,  this  is  being  developed  in  conjunction  with 
the  PDES  AEC  Committee .  The  Distribution  Systems 
Model  defines  engineering  systems  whose  function 
is  to  distribute  fluids  or  energy  including,  3- 
dimensional  piping,  electrical  and  HVAC  systems. 
The  developers  of  the  model  have  a  primary 
orientation  to  shipboard  systems,  however,  the 
content  and  structure  of  the  information  defining 
these  products  are  transferable  across  industries. 
In  this  way  the  marine  community,  through 
NIDDESC,  is  making  a  contribution  toward  the 
general  goal  of  CAD  integration  through  the 
development  of  international  standards .  The  model 
is  focused  on  the  definition  of  elements  which 
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comprise  the  distribution  system  including  shape, 
topology  and  geometry.  The  life  cycle  focus  is  on 
the  detailed  design  phase  and  the  development  of 
production  data. 

Many  organizations  are  contributing  to  this 
effort  by  reviewing  and  commenting  on  the 
contents  of  this  model .  As  a  result  it  is  being 
continually  revised.  The  figures  that  follow 
represent  the  state  of  the  model  as  it  was 
developed  in  April  1989.  This  model  is  scheduled  to 
be  submitted  to  the  PDES  organization  in  October 
1989.  in  the  following  discussion  a  general 
overview  of  the  model  will  be  presented.  The 
complete  model,  in  its  latest  form,  can  be  found  in 
Reference  (7] . 


Part  Attribute  Set  which  contains,  among  other 
things,  explicit  part  geometry.  If  a  part  is 
referenced  from  a  standard  parts  catalog,  then  it 
is  described  by  a  Catalog  Reference  Part  Attribute 
Set. 

CONCLUSION 

NIDDESC  is  an  unqualified  success .  Three  years 
ago  the  Navy  and  the  marine  industry  were  non¬ 
players  in  the  digital  data  exchange  standards 
world  and  their  needs  were  being  ignored.  For 
example,  draft  versions  of  PDES  at  that  time  did 
not  support  the  concept  of  a  volume  bounded  by 
surfaces  such  as  a  ship  compartment.  Today, 
through  NIDDESC,  the  Navy  and  the  marine 
industry  is  an  acknowledged  leader  in  digital  data 
exchange . 


Definitions.  Figure  6  shows  the  hierarchy  of 
systems  and  parts  in  the  Distribution  System 
Model.  In  this  diagram  all  part  classes  are 
subtypes  of  the  System  Part .  The  concept  of 
inheritance  is  used  so  that  attributes  and  other 
detailed  information  are  conveyed  to  subtypes  from 
the  parent  supertype.  For  instance,  the  Piping 
System  Part  must  have  one  or  more  interface  ports 
because  it  is  a  subtype  of  the  Distribution  System 
Part.  The  following  definitions  apply: 

♦Distribution  System  Parts:  Parts  of  an 
engineering  system  that  distributes  fluids  or 
energy  within  the  ship. 

*  Devices :  A  part  of  several  systems  that  needs 
not  have  interface  ports .  Devices  tend  to  be 
more  complex  than  Distribution  System  Parts . 
Devices  may  occur  in  more  than  one  system. 

*  Instrument  A  Device  used  for  monitoring 
and/or  control  within  the  system. 

*  Equipment  A  complex  Device  that,  can  belong 
to  more  than  one  system  (e.g.  pump, 
compressor  or  heat  exchanger) . 

Relationships .  The  principal  relationships 
shown  in  the  figure  can  be  stated  as  follows: 

An  Engineering  System  Part  is  a  kind  of  System 
Part, 

Every  Engineering  System  Part  must  be  either 
a  Mechanical  System  Part,  a  Distribution  System 
Part,  or  a  Device. 

Every  Distribution  System  Part  connects  at  one 
or  more  Interface  Ports. 

Every  Distribution  System  Part  must  be  either 
a  Piping  System  Part,  an  HVAC  System  Part  or  an 
Electrical  System  Part. 

Every  Device  must  be  either  an  Instrument  or 
Equipment . 

A  Device  may  connect  at  any  number  of 
Interface  Ports. 

In  the  complete  model,  Piping,  HVAC  and 
Electrical  Parts  are  further  broken  down  into  their 
respective  part  types .  Figure  7  shows  the 
Part/Catalog  Relationships.  Catalogs  of  parts  are 
used  extensively  in  describing  ship  systems .  This 
figure  is  a  generalization  of  the  concepts  which  will 
be  applied  to  all  specific  parts.  Important  concepts 
here  are  the  relationships  between  Catalog 
Reference  Part  and  Specific  Part  and  the  different 
Attribute  Sets . 

In  short,  a  Part  can  be  explicitly  defined  or 
referenced  from  a  catalog  of  standard  parts.  If  a 
Part  is  explicitly  defined,  then  it  has  an  Explicit 


*  The  NIDDESC  Structural  Model  is  part  of  the 
PDES  First  Working  Draft  and  Its  international 
equivalent  ISO/STEP . 

*  The  NIDDESC  Distribution  Systems  model  is  well 
on  the  way  to  incorporation  in  PDES. 

*  The  NIDDESC  3-D  Piping  Application  Protocol 
has  been  found  to  support  the  needs  of  the 
process  plant  industry  as  well  as  the  marine 
industry.  It  will  be  incorporated  in  MIL-D- 
28000  during  1989. 

*  Many  change  requests  originated  by  NIDDESC 
participants  have  been  incorporated  in  IGES 
Version  4.0  or  are  being  incorporated  in  IGES 
Version  5.0. 

*  NIDDESC  has  established  a  track  record  of 
producing  top-quality  products  on  t  he 
schedules  promised. 

There  are  many  reasons  for  this  transformation: 

*  The  technical  qualifications  and  can-do 
attitude  of  the  participants . 

*  The  teamwork  displayed  by  NIDDESC  members 
from  different  companies  and  government 
activities  while  working  toward  common  goals . 

Their  cooperation  has  been  in  the  finest 
traditions  of  NSRP  and  REAPS  cooperative 
efforts. 

*  The  establishment  of  formal  POA&Ms  to 
structure  and  focus  NIDDESC  activities . 

*  Corporate  willingness  to  absorb  part  of  the 
cost  of  NIDDESC  operation  and  corporate 
tolerance  for  what  was  frequently  an  uncertain 
funding  s ituat ion . 

*  Navy  sponsors '  willingness  to  support  a 
project  aimed  at  a  general  benefit . 

*  The  utilization  of  information  modeling  to 
obtain  explicit  and  lasting  agreement  on  the 
information  to  be  transferred. 

The  authors  are  pleased  and  gratified  to  be 
associated  with  NIDDESC.  We  have  the  feeling  that 
at  the  end  of  our  careers,  we  will  look  back  and 
say,  "NIDDESC  was  an  effort  that  really  made  a 
difference .  " 
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